apps/mobile/modules/t3-websocket/ios/T3WebSocketModule.swift (1)

30-37: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick win

Report dropped sends instead of returning silently.

sendBinary drops the frame when base64 decoding fails. send (line 95) drops the frame when no task exists for id. The JS adapter receives no signal in either case, so a caller sees a successful send() for data that never left the device. Emit onError on both paths.

♻️ Proposed change

     Function("sendBinary") { (id: Int, base64: String) in
-      guard let data = Data(base64Encoded: base64) else { return }
+      guard let data = Data(base64Encoded: base64) else {
+        self.connections.reportError(id: id, message: "Invalid base64 payload")
+        return
+      }
       self.connections.send(id: id, message: .data(data))
     }

Add the helper and the missing-task signal in T3WebSocketConnections:

func reportError(id: Int, message: String) {
  queue.async { self.emitLocked(id: id, event: "onError", payload: ["message": message]) }
}

func send(id: Int, message: URLSessionWebSocketTask.Message) {
  queue.async {
    guard let task = self.tasksById[id] else {
      self.emitLocked(id: id, event: "onError", payload: ["message": "Socket is not open"])
      return
    }
    // ... existing send
  }
}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/mobile/modules/t3-websocket/ios/T3WebSocketModule.swift` around lines 30
- 37, Update sendBinary and T3WebSocketConnections.send to report failed sends
through onError instead of silently returning: use a
T3WebSocketConnections.reportError helper for invalid base64 input, and emit an
onError event with “Socket is not open” when no task exists for the requested
id. Preserve the existing send behavior for valid data and open sockets.

apps/mobile/src/lib/nativeWebSocket.test.ts (1)

106-131: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Add coverage for onError and for protocol forwarding.

The suite does not exercise handleError or the protocols argument. handleError dispatches an Error instance rather than an event object, which is the least obvious part of the adapter contract. A short test for each closes that gap.

💚 Suggested tests

it("dispatches native errors and forwards protocols", async () => {
  const construct = await loadNativeWebSocketConstructor();
  const socket = construct!("wss://example.test/ws", ["t3"]);
  expect(lastCall("connect")!.args[2]).toEqual(["t3"]);

  const id = connectionIdOf(socket);
  const errors: unknown[] = [];
  socket.addEventListener("error", (event) => errors.push(event));
  mocks.emit("onError", { id, message: "boom" });
  expect(errors[0]).toBeInstanceOf(Error);
});

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/mobile/src/lib/nativeWebSocket.test.ts` around lines 106 - 131, Add test
coverage in the native WebSocket test suite for the constructor’s protocols
argument and the onError path handled by handleError. Instantiate the socket
with a protocol list and assert connect receives it, then emit onError, capture
the error event, and assert the dispatched value is an Error instance.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes